updates about response tables and appendix B by loumir · Pull Request #67 · ivoa/HighEnergyObsCoreExt

loumir · 2026-08-31T19:27:37Z

Hi,
here is an update about the response table description and uses cases adjusted for it.
next pull request will mention changes proposals on the Usecase part.

iannevans

Added several comments.

iannevans · 2026-09-01T08:42:10Z

 {\em resp\_energy\_max} & eV & double & Energy band maximal value for response use  \\\hline

-\caption{Example Response Table.  With appropriate further study the columns identified herein could form the basis for a recommended base set of columns for any {\tt ivoa.response$\{$\_xxx$\}$} table.}
+\caption{Proposal for a standard response table :  with appropriate further study the columns identified herein could form the basis for a recommended base set of columns for the  {\tt ivoa.response} table.}


I agree and the sentence explains it is some work to be continued .
Thanks

iannevans · 2026-09-01T08:50:58Z

+}% end \small
+
+
+


There is something wrong with this example. The number of opening and closing parentheses do not match. Did you intent to have an embedded SELECT on line 85?

iannevans · 2026-09-01T08:52:01Z

+{\em energy\_min\/} & \ucd{em.energy;stat.min} & eV & double &  {Energy associated to the ObCcore attribute {\em em\_max\/}, describing the minimal energy of the dataset} & NO \\
 \hline
-{\em energy\_max\/} & \ucd{em.energy;stat.max} & float & eV & {Energy associated to the ObsCore attribute {\em em\_min\/}, describing the maximal energy of the dataset} & NO \\
+{\em energy\_max\/} & \ucd{em.energy;stat.max} & eV & double & {Energy associated to the ObsCore attribute {\em em\_min\/}, describing the maximal energy of the dataset} & NO \\


Thanks for catching the swapped columns here.

iannevans · 2026-09-01T09:02:07Z

+
+The {\tt ivoa.response} table uses a specific resp\_dataproduct\_type column which is compliant to the response type vocabulary : \url{https://www.ivoa.net/rdf/response-type/} and has its own resp\_obs\_publisher\_did column as well, in order to distinguish which response matches  which ObsCore data set in the {\tt ivoa.response} table. 
+
+\subsection*{Proposal for a Response Table {\tt ivoa.response}}


This is not something that we have considered with sufficient due diligence that the HEIG can call this a "Proposal" at this time. At best for now we could say "Possible response table". Considerable extra discussion is required to come up with a "proposal" for table(s) that describe response functions.

I agree there is still more exploration to stabilize this but isn't "Proposal" something we can discuss and amend later? may be proposal and possible have different flavors in French and English ...

In the context of a note such as this from the HEIG to the TCG/WGs, a "proposal" would be something that HEIG has internally agreed is appropriate and is proposing to the TCG/WGs for adoption. In English, it would not be interpreted as being a proposal from some members of the HEIG for further internal review by the entire group. Maybe a difference in interpretation between English and French.

I'd be willing to use "Preliminary Proposal" or "Possible Draft Proposal".

If one of those is OK, I can accept the PR and I'll work on the formatting (something is still wrong in that section - too much of the text is now appearing as \scriptsize so I suspect a "}" is misplaced somewhere) and folding in the comments from Karl and Matthias, while you work on your Use Cases PR.

I am fine with both titles "Preliminary Proposal" or "Possible Draft Proposal".. . thanks

iannevans · 2026-09-01T09:04:09Z

+In order to handle the various possible cardinality relationships between {\bf response-function} and {\bf hea-event-list}  datasets, foreign keys must be defined in the {\tt ivoa.response} tables that will allow {\tt  JOIN} operations between those tables and the {\tt ivoa.obscore} table.
+
+The {\tt ivoa.response} table uses a specific resp\_dataproduct\_type column which is compliant to the response type vocabulary : \url{https://www.ivoa.net/rdf/response-type/} and has its own resp\_obs\_publisher\_did column as well, in order to distinguish which response matches  which ObsCore data set in the {\tt ivoa.response} table. 
+


So it seems that this table is more about identifying linkages between response functions and the datasets to which they are applied rather than identifying response functions based on query attributes needed to identify them, and that is the reason that only a single table is required (because those query attributes which will be different for different types of response functions) are not required to be present?

That is OK, but would not for example allow one to identify and retrieve a psf based on off-axis angle and azimuthal angle in the telescope-frame. One could add additional columns to the table, but then those columns would not be meaningful for other types of response functions.

I presume that this solves the cardinality problem by allowing you to have multiple records in this table with different pairs of obs_publisher_did and resp_publisher_did.

If this is the case I don't see that ra, dec, and region (and perhaps t_intervals, energy_min, energy_max) are useful columns to have separately in this table as they are very unlikely to be the set of attributes necessary to uniquely identify different types of responses independently. If you have to come in via the obs_publisher_did linkage it's OK, since in most cases a single response function will only apply to a single linked dataset. However, there may be some cases (with psf being the most likely example) where a single response function might apply multiply to multiple datasets. ra, dec, region etc. would work well for the HESS psf example, but this is not generalizable.

Also in this case, why are obs_id and obs_publisher_did both required as foreign keys, as the latter is unique and therefore imputes the former?

At this point, consideration from HEIG domain experts is still required.

Also in this case, why are obs_id and obs_publisher_did both required as foreign keys, as the latter is unique and therefore imputes the former?
I changed the text : only one foreign key is required.

If this is the case I don't see that ra, dec, and region (and perhaps t_intervals, energy_min, energy_max) are useful columns to have separately in this table as they are very unlikely to be the set of attributes necessary to uniquely identify different types of responses independently.

I use these fields in the SELECT to check them in the query response .

iannevans · 2026-09-01T09:05:15Z

 \noalign{\vspace{8pt}}
 \hline
-\multicolumn{4}{|r|}{\bf Considered for addition to an IVOA Analysis Data Product Vocabulary\footnote{As noted in \S~\ref{sec:dataproduct_type}, we prefer the term ``Advanced Data Product'' rather than ``Analysis Data Product'' since the latter suggests that additional steps ({\em i.e.\/} some type of analysis) have taken place to construct these data products, which may not be the case.}$^,$\footnote{\url{https://github.com/ivoa-std/VEPs/pull/21/changes\#diff-25a867536b53bdb6848baeba09cfc4df1e4ad42da919d440902e57b917dd9abc}.}} \\ \hline
+\multicolumn{4}{|r|}{\bf Considered for addition to an IVOA Advanced Data Product Vocabulary} \  \\ \hline


iannevans · 2026-09-01T09:51:18Z

 {\bf region}: A dataset that includes an encoding of (one or more) regions of parameter space, for example a spatial region or a region of phase space covered by a dataset.  The set of dimensions represented by the region can be arbitrary.
 \end{quote}

+An advanced-dataproduct-type Vocabulary \footnote{\url{https://github.com/ivoa-std/VEPs/pull/21/changes\#diff-25a867536b53bdb6848baeba09cfc4df1e4ad42da919d440902e57b917dd9abc}.} is proposed to the Semantics WG to register these terms in a standard vocabulary, that can be extended to other spectral domains, e.g radio astronomy.  


The footnote url string needs to be in a smaller font or manually split across lines. The long hash is causing the footnote to run off the right edge of the page.

I tried to clarify the query. The idea is to restrict the search based on the scan_mode column and data set ids and apply the join with response table to a smaller subset .

Clarified the joining keys in the response table explanation.

Updated the formatting of the URL in the ivoa.response table description to use a smaller font size.

loumir

a few updates to the text, as suggested by the comments .
Thanks

updates about response tables and appendix B

c21dd6d

iannevans requested changes Sep 1, 2026

View reviewed changes

loumir added 3 commits September 1, 2026 17:09

Refactor SQL query for response and observation join

004a437

I tried to clarify the query. The idea is to restrict the search based on the scan_mode column and data set ids and apply the join with response table to a smaller subset .

Update about keys used for join in response table

c0b5640

Clarified the joining keys in the response table explanation.

Adjust URL formatting in ivoa.response table section

6d7014e

Updated the formatting of the URL in the ivoa.response table description to use a smaller font size.

loumir commented Sep 1, 2026

View reviewed changes

loumir requested a review from iannevans September 1, 2026 15:52

iannevans merged commit 26739a0 into ivoa:main Sep 1, 2026
1 check passed


		The {\tt ivoa.response} table uses a specific resp\_dataproduct\_type column which is compliant to the response type vocabulary : \url{https://www.ivoa.net/rdf/response-type/} and has its own resp\_obs\_publisher\_did column as well, in order to distinguish which response matches which ObsCore data set in the {\tt ivoa.response} table.

		\subsection*{Proposal for a Response Table {\tt ivoa.response}}

		In order to handle the various possible cardinality relationships between {\bf response-function} and {\bf hea-event-list} datasets, foreign keys must be defined in the {\tt ivoa.response} tables that will allow {\tt JOIN} operations between those tables and the {\tt ivoa.obscore} table.

		The {\tt ivoa.response} table uses a specific resp\_dataproduct\_type column which is compliant to the response type vocabulary : \url{https://www.ivoa.net/rdf/response-type/} and has its own resp\_obs\_publisher\_did column as well, in order to distinguish which response matches which ObsCore data set in the {\tt ivoa.response} table.

Conversation

loumir commented Aug 31, 2026

Uh oh!

iannevans left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

loumir left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants